The only controversial thing is the FromIterator impl. In particular, there's a few different ways it could be implemented:

• Accept AsRef<JsValue> (which is what this PR does)

• Accept Into<JsValue>

• Accept something else?

Using Into<JsValue> is good, it allows for some native types like &str, u32, etc. But it doesn't work for certain things, like Closure

Using AsRef<JsValue> is very good, but it does require the user to manually call JsValue::from for things like &str, u32, etc. This isn't a big deal, they can just do .map(JsValue::from)

Another issue with AsRef<JsValue> is that it doesn't (currently) work with #[wasm_bindgen] structs, because they don't implement AsRef<JsValue>. Is there any technical reason they can't impl AsRef<JsValue>?

Thanks! This all seems great to me, and I'm fine with AsRef chosen here.

Is there any technical reason they can't impl AsRef?

Currently they don't actually have the JsValue on-hand anywhere in the struct to implement AsRef with, we don't actually modify the struct we just generate a wrapper around the struct. I saw a comment from you about this on another thread though that I haven't gotten to, so I may be missing something as well.

Currently they don't actually have the JsValue on-hand anywhere in the struct to implement AsRef with, we don't actually modify the struct we just generate a wrapper around the struct.

Ahhh, right. So in that case if a user wants to send a struct they'll have to use .map(JsValue::from), just like with native types. That's fine, after all Rust structs are a native type.

👍